perm filename GIO.S1[D,LES] blob
sn#403162 filedate 1978-12-09 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00022 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 ∂06-Dec-78 1545 Wiederhold at SUMEX-AIM final
C00004 00003 Page 1
C00011 00004 Page 2
C00015 00005 Page 3
C00019 00006 Page 4
C00023 00007 Page 5
C00026 00008 Page 6
C00029 00009 Page 7
C00034 00010 Page 8
C00038 00011 Page 9
C00042 00012 Page 10
C00047 00013 Page 11
C00051 00014 Page 12
C00056 00015 Page 13
C00061 00016 Page 14
C00066 00017 Page 15
C00069 00018 Page 16
C00073 00019 Page 17
C00076 00020 Page 18
C00078 00021 Page 19
C00080 00022
C00096 ENDMK
C⊗;
∂06-Dec-78 1545 Wiederhold at SUMEX-AIM final
Date: 6 Dec 1978 1543-PST
From: Wiederhold at SUMEX-AIM
Subject: final
To: les at SAIL
FINAL REPORT, S-1 SOFTWARE DEVELOPMENT
SUBMITTED TO
LAWRENCE LIVERMORE LABORATORY
BY
DEPARTMENT OF COMPUTER SCIENCE
SCHOOL OF HUMANITIES AND SCIENCES
STANFORD UNIVERSITY
FOR
PERIOD OF DECEMBER 1, 1977 to NOVEMBER 30, 1978
Assistant Prof. Gio Wiederhold, Principal Investigator
NOVEMBER 1978
Page 1
This is a final report on Contract No. 90-83403 between the Regents of the
University of California and Stanford University, entitled "Proposal for
S-1 Software Development [revised], October 1977"; for work on software
and language development for the Advanced Technology Processor. It covers
the period from December 1, 1977 to November 30, 1978. The period
included two extensions; one for work on the project through the summer
and a no-cost extension which covered the months of October and November.
This extension was required because we have initially had some problems in
attracting people of adequate competence to the project. We are now
reasonably staffed for the tasks at hand and progress in recent months has
been very satisfactory. Additional material related to this contract has
appeared in the proposal for this period, interim reports for this
contract dated May 1 and August 1, 1978, and in the current Proposal for
S-1 Software Development and Maintenance dated August 1, 1978 of this
contract.
Nearly all of the programming has been done on machines located at
Stanford University, and the principal resource is the DEC PDP-10 at the
Stanford University Artificial Intelligence Laboratory (SU-AI). The
availability of this equipment has been supported through a parallel
contract from LLL for S1 Operating Systems development with Prof. J.
McCarthy, director of the laboratory. During the winter quarter of
1977-78 we moved all of our software to SU-AI. We rely in our work on the
availability and cooperation of the laboratory and its personnel. The
PASCAL compiler [JeW75], which forms the basis of our work is fully
operational on DEC PDP-10 computers at SU-AI and LOTS, and on the IBM-370
at SLAC. Testing has being accomplished through the use of an S-1
simulator constructed at SU-AI, a few programs have used the S-1 processor
itself via a remote access link.
The primary objective for this contract is the development of language
processors and support programs for applications of the S-1 Advanced
Technology Processor[MWW77]. Much of this work is now substantially
complete and most of the sub-projects are in maintenance or enhancement
status. The products consist of a Pascal[JeW75] compiler (PCPASC) adapted
from previous work at SLAC[Haz], with suitable modifications for the S-1,
a Fortran[ANS66] compiler(PCFORT)[ccn78], a translator to S-1 machine code
from the intermediate P-code [giw77] language (SOPA) [wag78], and a
linking loader (LINK) [kew78], which can combine the binary code modules
generated by SOPA and by the assembler (FASM, developed at SAIL) for
loading into the machine. The SOPA translator now includes also a number
of peephole optimizations and one optimization which simulates an
important global optimization. Documentation has been created for all the
products that have been created. In addition, a user manual[hhw78] has
been written for the S-1 processor itself to allow broader access to its
unique architecture. Examples for the manual were provided by Marc LeBrun
from the SAIL staff. This manual also includes the description of FASM
and FSIM, provided by Jeff Rubin. A sophisticated linkage protocol,
designed to encourage the use of highly modularized code procedures has
been defined and documented under the guidance of Curt Widdoes[kwz78].
The extensive use of registers for parameter and environment passing
should minimize the overhead commonly associated with procedure calls. We
still have to complete a user-oriented manual for Pascal to complement the
standard Pascal documentation and an implementation manual for the linker
so that maintenance can be taken over easily by people other than the
implementor.
Page 2
We have a high degree of confidence in the intrinsic quality of the
generated software. The fact that all software is written in a carefully
designed manner, using structured techniques and a complementary
high-level programming language has indeed demonstrated its benefits. In
all modules the number of errors discovered when debugging started was
low, and the incidence of error occurrences showed a rapidly declining
rate, so that we can confidently extrapolate a continuing low level of
debugging type maintenance as the modules enter more intensive service.
On the other hand, we expect that continuing maintenance will be needed to
satisfy the ongoing development of S1 hardware and software. The
development of the Mark II, the introduction of a P-code optimizing module
by a cooperating project (Sites at UCSD), and the development of new
linkage and system conventions will continue to affect S1 software, and
lead to significant maintenance efforts. We have invested within this
period in the training and development of people which we can expect will
to be available and interested over several years, so that a continuing
low level of maintenance can be provided in an expeditious manner.
All of the software tools work in a Pascal/P-Code[NAJ75] oriented
environment so that compatibility with further developments here, both in
the CS and SAIL groups, can be assured. We also expect to benefit from
optimization work on P-Code being carried out by Dick Sites' group at
UCSD[Per78]. Integration work currently in progress includes the merging
of the numerical function procedures developed at SAIL into the Pascal and
Fortran environment. Testing of substantial Fortran programs is now in
progress and substantial Pascal programs, including the SOPA translator
itself, have been translated into operational code for the S-1 processor.
The linker has taken PASCAL and FASM programs and combined them into
executable codes for the simulator (FSIM).
Page 3
Future work required includes the development of support for operating
systems and the operating systems proper. At this point we are still
using the zero-level OS-Operating system [haw78], developed in 1977 under
the predecessor contract and completed during the initial period of this
contract, and an equivalent microcoded set of functions on the S-1 proper.
Basic issues of operating systems development strategy [wie78] are still
being discussed. Their resolution can simplify the work needed to make
the S-1 project a demonstration of advanced software techniques and their
capabilities, as it is now a demonstration of advanced hardware design
techniques and their capabilities.
In order to support further software development, several subprojects are
in progress. They include the implementation of a macroprocessor so that
programs can be effectively parameterized to serve in a variety of
different configurations and environments. Extensions to Pascal[Wir75] in
order to cleanly specify access to the variety of data formats on the S-1
are being defined[heb78]; their implementation should be straightforward
since the SOPA translator already supports a great deal of the facilities.
An internal reorganization of the Pascal and SOPA interface which will
allow bit-oriented addressing and hence packing of data into words on a
bit-by-bit basis, is being evaluated. Such a facility will greatly
enhance the ability to construct dense representations of information as
is often required in operating systems[BHM77]. Implementation of bit
addressing will proceed when the design has been completed to an extent
what a straightforward and secure changeover can be foreseen. Such a
change will also affect the Fortran compiler, although we do not foresee
that the Fortran compiler will take advantage of this capability. The
three tasks outlined in this paragraph are independent of actual operating
systems decisions and are hence already being undertaken.
Page 4
Highly dependent on operating system design decisions will be the
facilities for system and user files, as well as the designs for flexible
and comprehensive file access eprocedures. We would like eventually to
implement a comprehensive set of file routines as defined for instance by
the PL/1 language since these form an adequate basis for further
implementation of database-oriented applications for the S-1. Advanced
file techniques will also enhance the S-1 as an application development
system, since we expect to deal both with large and substantive programs
and large and substantial collections of data.
The number of tools that now have been developed for the S-1 has the
effect that a continuing effort has to be devoted to the maintenance of
the developed software tools. As requirements on the software increase,
as the S-1 hardware and software systems are augmented with new modules,
and as users of the S-1 become more sophisticated, corresponding
maintenance work has to be carried out to keep the entire software system
operating as one integrated and productive whole. As more demands
exercise the developed software to a greater degree we will undoubtedly
also find areas which require enhancement and bugs which require
correction. A major enhancement task in the future is the installation
and conversion to the complex linkage protocol developed during this
summer. While we have trained several people specifically for maintenance
tasks, the change to the new linkage convention will have to be delayed to
a point where we are assured that adequate resources are available to make
the change in an expeditious manner.
In summary, we have achieved the primary goal of this contract, a
comprehensive language and software development system that enables us to
support both conventional programs written in Fortran and new development
programs which we expect to be written in Pascal. We have accordingly
provided the basis for further support of the system development efforts
that are needed to make the S-1 into a flexible multiprocessor system
which can support a variety of applications.
Page 5
TECHNICAL SUMMARY
The proposal recognized thirteen areas of work during its period. Some
areas have been completed, others were discontinued, and some are still
active. The shift of the project from the IBM systems at the Computer
Facility of the Stanford Linear Accelerator (SLAC) to the DEC systems at
the Stanford Artificial Intelligence Laboratory (SAIL), which occurred
during this contract period has had major effects.
One effect has been that work on some tasks could be discontinued;
specifically the simulator and the assembler. Staff from SAIL were able
to produce on short notice a simulator and an assembler, which, using the
facilities of a computer architecture which is similar to the S-1 are able
to support development until all software has to be able to execute on the
S-1 processors themselves.
The other effect has been of course that effort had to be devoted to the
transfer of programs and software tools. This has been possible since all
programs were written in PASCAL, so that source programs were largely
compatible. For those people on our project who did not have previous
experience at SAIL, time was needed to familiarize themselves with the new
environment. The improved programming support available at SAIL, and the
good communication facilities has increased productivity of our people
greatly over the levels achieved at SLAC. The ability to communicate
notes, proposals, documentation, and programs over the ARPA-net has been
equally important, and has made the S-1 project cohesive while its members
are at locations throughout the United States.
Page 6
PROGRESS REPORT BY TOPIC
1. SIMULATOR
The initial period saw continuing work on the PASCAL written simulator
for the S-1 instruction set. Specifically a loader interface and
floating point arithmetic were developed. As indicated in the summary
the move to SAIL made further work on the simulator futile and as of
February no further effort has been expended on the simulator.
2. SOPA MAINTENANCE AND OPTIMIZATION
MAINTENANCE The P-Code to S-1 machine code translator (SOPA) was
developed during the predecessor contract, and has seen mainly
refinement and documentation during this contract. The source code was
transferred to SAIL, adapted to the intermediate loader format and
interfaced with the simulator. It was tested on a variety of
programs, including a test program received from Lawrence Livermore
Labs and its own code. Some incompatibilities due to characterset
differences introduced during the transfer were initially bypassed,
but have been resolved now so that a full 128 ASCII character set can
be supported. Soon decisions will have to be made about usage of the
9-bit, 512 character space of the S1 [wie77]. Future efforts on SOPA
will include conversion to a bit-oriented addressing scheme to enhance
usability for systems work. Adaptation to the new linkage protocol
[kwz78] will await availability of staff. A major item produced
during this period is SOPADOPE, a maintenance manual for the
translator [wag78]. This document makes it possible to transfer the
maintenance responsibility from the originators of the code to new,
competent staff, and insures long-term viability of the program.
Page 7
OPTIMIZATION IN SOPA The high instruction code density which is
designed into the S-1 architecture makes optimization of the generated
code and important item. Whereas in simpler machines the translation
of source language statements to the machine language is mainly a
problem of expansion of the code, the instruction set of the S-1
permits large segments of source language statements to be collapsed
into a single or a few instructions. A technique for doing part of
this operation is called "peephole optimization" and during this
contract a number of peephole optimizations have been investigated and
several have been implemented. Particularly jumps which had
themselves other jump instructions as destinations are now being
collapsed into direct jumps. Combinations of skip and jump are
translated to jumps in the opposite direction whenever feasible.
Since many arithmetic instructions generate results which are to be
moved in memory to their destination, the peephole optimizer checks
for this possibility and collapses move instructions which follow
arithmetic instructions into combined instructions whenever feasible.
The combination of increment and skip can also be collapsed and this
is a frequent occurrence in inner loops. Another type of optimization
which is better done on a global level, but in the absence of a global
optimizer system has been implemented within SOPA itself, is the
recognition of certain common subexpressions. Whereas programmers
frequently avoid the use of common subexpressions, in operations on
arrays with complex subscripts repeated use of such expressions cannot
be avoided. The extended peephole-like optimizer remembers previous
use of subexpressions and will use the results of such previous
computations whenever possible. The optimizations cited have been
measured on programs that exhibit these types of behavior and have
been shown to be quite effective.
3. LEVEL 0 OPERATING SYSTEM
Specifications for an initial operating system, which makes LSI-11
based functions of DEC's RT-11 operating system available to S-1
programs were completed; the system was completed and checked out, and
was used through the simulator to validate other software.
Documentation for the system is available [haw78]. This program is
written in S-1 assembly language. Further maintenance is being
carried out at SAIL. This system provides the required services for
the checkout of the S-1 processor, and will be used until a multi-user
system is available.
Page 8
4. RUN-TIME FOR P-CODE
To support testing a basic run-time a support package has been
provided, and PASCAL programs for input-output including floating
point conversion have been implemented. These programs, together with
available facilities at SAIL, have been adequate to support systems
development and testing. These programs have been mainly utilized
through the FSIM simulator at SAIL, but are now moving to the S-1
hardware prototype. PASCAL programs also have access to the Fortran
run-time package in case formatted input-output becomes desirable.
5. LIBRARY SUPPORT INTEGRATION
Lawrence Livermore has contracted with SAIL to provide a subroutine
library. Basic arithmetic function are now available and checkout is
now in progress. Previous work used the DEC-10 library at SAIL or
PASCAL coded algorithms within the source code. Related work performed
has been the implementation of the linker facilities needed to load
these routines with compiled code. For Fortran programs routines for
complex arithmetic still have to be made available.
6. MODIFICATION OF PASCAL (PCPASC)
PASCAL compiler source codes have been transported from SLAC to SAIL
and adapted to the new environment. PASCAL is the mainstay of the S-1
development effort. The main change has been an adaptation to better
manage sets of type character, which however expands to all set
operations in PCPASC. The set size is now 144, which means that the
full ASCII character set will fit into a PASCAL set; the primitive
type CHAR includes now all of ASCII. Change of a compile parameter in
PCPASC will allow a change of compiler set size by multiples of 72.
The language has been otherwise found adequate to the task, but we
realize that operating systems work will demand additional constructs.
The MODEL language, a PASCAL derivative developed at Los Alamos, has
been considered, but since the effort at Los Alamos has been reduced
we expect to further develop PASCAL[heb78].
Page 9
7. ASSEMBLER
A PASCAL written assembler for the S-1 has been completely programmed
and testing had begun. Due to the transfer to SAIL further work has
been limited to documentation and archiving. Continued work on this
assembler is doubtful. Currently used is the FASM assembler written
in FAIL, a DEC-10 assembly language.
8. FORTRAN (PCFORT)
The FORTRAN compiler PCFORT, was written specifically to serve in a
PASCAL environment, using P-Code as an intermediate pseudo machine
[NAJ75]. The need for implementation of FORTRAN these days is due to
the great volume of existing FORTRAN programs, rather than to a desire
to have this language available to develop new programs. We have
hence implemented the full, but traditional FORTRAN standard [ANS64,
ANS66], rather than the recently adopted augmented FORTRAN standard
[ANS76]. All aspects of Fortran which are commonly used in large
scientific programs are available, including features as SUBROUTINES,
labelled COMMON, and COMPLEX arithmetic.
The foremost objective in the design of this compiler is the
generation of correct code. Effects of this objective are a clean
approach to the design of the compiler, the use of PASCAL as the
implementation language, and the use of a simple one-pass compiling
technique. The one-pass approach has led to two additional
constraints on the source language: variable declarations, if given,
must precede all executable statements within each program unit, and
keywords must be separated from variable identifiers by a blank.
These constraints are commonly followed by programmers, but not part
of the standard. A pass over FORTRAN source code with a text editor
can easily correct failures to obey that constraint, since these
changes do not affect the semantics of FORTRAN programs in any way.
We feel of course that such constraints are a reasonable part of any
programming environment we wish to support.
Page 10
The structure of the compiler is derived from a FORTRAN compiler,
written in FORTRAN, which was used for student programming from 1963
to 1967 at UC Berkeley ($tudent) on an IBM 7094 system. A derivative
of that compiler is the PL/ACME compiler [BrW68], a compiler for a
subset of PL/1, also written in FORTRAN, with strong support for
on-line laboratory operations. Writing the new compiler in PASCAL has
allowed formalization of modular concepts used in the earlier
compiler[WiB70]. The availability of recursion has caused us to
switch to the use of recursive descent as the method for compiling
arithmetic instructions, a method which copes better with some of the
problems of FORTRAN syntax.
The compiler, while attempting to generate good P-Code, does no
explicit optimization of generated code. Recognition of common
subexpressions, for instance, will require at least an additional pass
in a compiler. Current research in the PASCAL/P-Code project at UCSD
may lead to such an optimizer operating on P-Code. Some expressions
can be recognized and optimized within SOPA. The compiler is also not
aware of the register structure in the underlying machine. It is the
function of the P-Code compiler SOPA to carry out the requested
P-machine actions in a manner which utilizes the underlying hardware
effectively.
PCFORT does not depend on reserved words in its method to recognize
keywords and is hence extensible to additional statement types.
Candidates for additions are several file manipulation statements, now
used by existing compilers and defined in ANS76, and other features to
support real-time operations and aspects of parallel processing.
LRLTRAN can provide examples of such extensions. Which LRLTRAN
features will be added will depend on sample programs received from
LRL. The extent to which LRLTRAN features make sense for the S1, and
are reasonable within the constraints of keeping PCFORT and SOPA clean
is to be assessed soon. The size of S1 Fortran (PCFORT) is now 8600
lines of Pascal, generating a relocatable module of 70 K words. In
contrast DEC Fortran ( F40 ) is written in 13000 Lines of MACRO, it
occupies 10 K words. The actual code is of course generated by SOPA,
which is now about 10000 lines of Pascal and occupies 90 K words.
Page 11
9. RUNTIME SUPPORT FOR FORTRAN
A substantial set of input-output and numerical routines are required
in order to support execution of generated code from the compilers for
the two source languages. A comprehensive runtime package for Fortran,
including formatted I/O, has been part of the Fortran project. Runtime
support packages can be shared to a large extent between modules
generated from Pascal and Fortran source code. The runtime package
for Fortran is in fact written in Pascal. We await the addition of
double precision capability in PASCAL in order to handle double
precision input and output. Numerical routines developed at SAIL are
now being integrated into the common runtime environment for the
software language system. Additional routines will be required to
fully support the complex arithmetic features for Fortran. Eventually
file-oriented runtime support routines will be needed within the
system to provide access to file directories, blocks of data stored on
files, and to support record oriented direct file access so that
flexible data files will become available to the users.
10. P-CODE OPTIMIZATION
The status of P-Code work at Los Alamos was investigated. A separate
contract was then let which will allow the project to share in the
development of the the P-Code optimizer begun in Los Alamos[Per78],
and now part of the microprocessor PASCAL-P-Code project at U.C. San
Diego. Since the date of availability for the optimizer is not yet
clear we have placed one important global optimization into the SOPA
processor itself, as described above.
11. LINKER
The design and implementation of a linker for the intermediate and
portable linker format [kew78] has been completed. The linker has
linked modules together that originated from Pascal, Fortran, and FASM
source codes. The linker is an important aspect of system integration
and all of projects have contributed their ideas. The external
documentation is up-to-date and a maintenance manual is to appear.
The specification for the production linker has been updated [okk78].
Page 12
12. OPERATING SYSTEM DEVELOPMENT
Work under this contract on the preliminary operating system has been
completed, as indicated above. Conceptual issues to bring operating
system into existence are being discussed here [wie78], at MIT[han77],
and at SAIL. The experience brought into the project by Prof. Baskett
from the DEMOS operating system [BHM77] for the Cray-1 will be
important to the entire project. LASL[Rus78,BaK77]. The SOLO Operating
System[B-H75-2] and its support language, Concurrent Pascal[B-H74,
B-H75-1&-3]; and other operating systems such as UNIX[RTh76] in order
provide models of concepts, design, or perhaps even code which may be
adapted to the S-1 architecture and goals.
13. MULTIPROCESSOR OPERATING SYSTEM
The viability of Multiprocessor Operating Systems has been assessed
[wieM77], and an overview study is in progress to determine desirable
alternatives for process communication, evaluate experience with the
various alternatives, assess specific features, and provide guidelines
for language selection. No final results are yet available, and we
expect to coordinate our efforts closely with those of SAIL.
OTHER ACTIVITIES
Some time was spent, and travel was supported, for researchers from MIT
who are active in LISP implementation. This language is the mainstay of
work in Artificial Intelligence, and it appears desirable and feasible to
have an effective LISP system on the S-1 computer.
Some effort was expended in the development and testing of demonstration
programs for the S-1. These programs also provide verification of the
software tools which have been developed.
A machine whose architecture is as flexible as the S-1 naturally engenders
a fair amount of discussion of system architecture and tradeoffs in
instruction sets and computational algorithms. The availability of the
ARPA-net has contributed immensely to a continuing discussion of
architectural issues, with participants at LLL, MIT, CMU, Los Alamos, and
Stanford. We expect that the scrutiny and public exposure among experts
will lead to a better system than would be otherwise possible. Much of
the discussion has centered on hardware issues. Up to this point our
software ambitions have been oriented towards well engineered versions of
standard languages and services. We hope that as the project develops
that language and operating system issues will undergo similar scrutiny.
Page 13
SIGNIFICANCE OF THE S-1 SOFTWARE EFFORT
The software which has been developed under these two contracts, namely
the language processors described above, a Level 0 Operating System
[haw78], and a number of utility routines, have permitted immediate and
effective testing of the extremely high-performance digital computing
hardware now under development in the Physics Special Studies Group at
Lawrence Livermore Laboratory[FiZ78]. As the project develops it remains
important to continue to devote a significant effort to the enhancement
and maintenance of "programming tools" which allow the capability of the
hardware to be fully exploited. The major effect of well designed
programming tools can be to greatly reduce the costs of writing software.
In view of the low cost of the S-1 Processing Element and the
undiminishing cost of software, it is extremely important to provide
programming tools which minimize programming costs.
A second effect of well designed programming tools can be to increase the
apparent performance level of the target machine. In view of the goal of
the S-1 Project to provide cost-effective digital computing for a specific
set of applications, it is important that the language tools allow the
hardware to be efficiently used. In order to retain flexibility in the
hardware to software interface we are using a tabular description of the
S-1 instruction set [nem77].
We have built our software strategy around the use of a higher level
language, namely PASCAL, and its intermediate form, P-Code. The language
PASCAL has been shown to be highly effective in reducing software costs.
PASCAL is block structured, and offers data typing which is largely
checked at compile time, so that PASCAL programs can execute at nearly the
instruction rate intrinsic to the hardware. Furthermore, PASCAL's set of
primitives is small enough to be intellectually manageable[Wir75].
PASCAL is also fairly easy to compile. We are using a PASCAL to P-Code
compiler which is available from the original authors and is widely used
as the first phase of PASCAL compilers [haz]. Only recently has it become
necessary to make modifications to the compiler, and the source language
has still remained unchanged. The use of the PASCAL to P-Code compiler
allowed most development time to be spent in writing the optimizers and
code generators included in the P-Code to S-1 Machine Language translator.
The simplicity of installing a PASCAL coded compiler for PASCAL has
enabled us to move compiler and programs from an IBM 370 to a DEC PDP-10
system in the middle of the last contract period.
Page 14
A demonstration that this approach is not restricted to a narrow area of
application has been provided by our FORTRAN project. Using PASCAL as the
implementation language, a compiler for full ANSI FORTRAN[ANS66] was
designed, implemented, and documented in 15 months by research assistants
on the project. Only the principal investigator had previous compiler
writing experience[BrW68]. The impressive aspect however is not the low
level of total manpower that was used, but rather the fact that the
compiler was brought up with very few errors, which bodes well for its
future reliability. Cost reductions in this area are essential both for
the S-1 project and for the future of computing in general [DRN78].
We expect that the major portion of the Operating System software for
support of the processor will be written in PASCAL or a similar high-level
language. This will permit an interchange of concepts and code among
researchers and developers in this active area, so that the S-1 system
will be able to continually benefit from ongoing work and its results.
The interfaces to the LSI-11 support processors used by the S-1 will be
written in Assembler, but all service routines will be written in PASCAL.
Extensions to our current PASCAL compiler and the PASCAL language that are
required for effective control of the hardware include finer control of
field-sizes and control of process initiation. These programs have to
access both the user and system domains in the S-1 in order to provide
high-level multi-programming and eventually multi-processing support. The
availability of a P-Code to S-1 Machine Language translator introduces
modularity into the task of providing an extended PASCAL compiler; the
PASCAL to P-Code compiler can be modified to accept the additional
constructs and the P-Code translator will be extended as required. We have
recently begun to lay the foundation for such adaptations. Other
candidates for S-1 language system support are MODEL [Mor76], the compiler
used to develop the DEMOS operating system for the Cray-1 at the Los
Alamos Laboratory, and C, the systems language use to write the UNIX
System, which is being adapted to P-Code in Vancouver. Other compilers
that translate to P-Code will also benefit from improvements made to the
P-Code translator, and also from the global P-Code to P-code optimizer
being developed at UC San Diego by Sites. We also expect to contact the
Concurrent Pascal project at the Tata Institute for Fundamental Research
in Bombay, where P-code based systems are being developed for
multi-processor systems[Jos78].
Page 15
REFERENCES
[ANS64] American Standard Association, X3.4.3: "FORTRAN vs. BASIC
FORTRAN"; Comm. of the ACM, Vol. 7, No. 10, October 1964, pp.
591-625.
[ANS66] ANSI: "USA Standard FORTRAN"; USA Standards Institute, USAS
X3.9-1966, New York 1966.
[ANS76] American National Standards Committee X3J3: "Draft Proposed ANS
FORTRAN"; Sigplan Notices, Vol. 11, No. 3, March 1976, (254
pages).
[BaK77] Forest Baskett and Tom W. Keller: "An Evaluation of the CRAY-1
Computer"; LASL-report, University of California, Los Alamos
Scientific Laboratory, 1977.
[BHM77] Forest Baskett, John H. Howard, and John T. Montague: "Task
Communication in DEMOS"; LASL-report UR-77826, University of
California, Los Alamos Scientific Laboratory, 1977.
[BrW68] Gary Y. Breitbard and Gio Wiederhold: "PL/ACME: An Incremental
Compiler for a Subset of PL/1"; Information Processing 1968
(Proceedings of the 1968 IFIPS Conference, Edinburgh), North
Holland, 1969, pages 358-363.
[B-H74] P. Brinch-Hansen: "Concurrent Pascal: Programming Language for
Operating System Design"; California Institute of Technology,
Information Science Department, Technical Report No. 10, 1974.
[B-H75-1] P. Brinch-Hansen: "Concurrent Pascal Report"; California
Institute of Technology, Information Science Department, 1975.
[B-H75-2] P. Brinch-Hansen: "The SOLO Operating System"; California
Institute of Technology, Information Science Department, 1975.
[B-H75-3] P. Brinch-Hansen: "The Programming Language Concurrent PASCAL";
IEEE Transactions on Software Engineering, vol SE-1, no. 2, pages
199-207, 1975.
[B-H77] P. Brinch-Hansen: "Experience with Modular Concurrent
Programming"; Transactions on Software Engineering, vol SE-3, no.
2, pages 156-159, 1977.
Page 16
[DRN78] Barry C. De Roze and Thomas H. Nyman: "The Software Life Cycle - A
Management and Technological Challenge in the Department of
Defense"; IEEE Transactions on Software Engineering, vol SE-4, no.
4 July 1978, pages 309-318
[FiZ78] Jim Finnel and Polle T. Zellweger: "The S-1 Multi-processor"; DSL
Technical Note 142, Stanford University, June 1978.
[Haz] S. Hazeghi, Stanford University Linear Accelerator Center,
Computation Group Internal Report (to appear).
[JeW75] K. Jensen and N. Wirth: "PASCAL User Manual and Report"; Springer
Verlag, New York, 1975.
[Jos78] Mathai Joseph, K. Nori, et al.: "An Implementation of Concurrent
Pascal"; TIFR Technical Report, 1978
[Mor76] James B. Morris: "A Manual for the Programming Language MODEL";
University of California, Los Alamos Scientific Laboratory,
revised report 1976.
[MWW76] T. M. McWilliams, L. C. Widdoes, and L. L. Wood: "The Preliminary
Design of an Advanced Programmable Digital Filter Network for
Large Passive Acoustic ASW Systems"; University of California
Lawrence Livermore Laboratory, UCID 17299, September 30, 1976.
[MWW77] T. M. McWilliams, L. C. Widdoes, and L. L. Wood: "Advanced Digital
Technology Base Development for Navy Applications: The S-1
Project"; University of California Lawrence Livermore Laboratory,
UCID 17705, September 30, 1977.
[NAJ75] K. Nori, U. Amman, K. Jensen, et al.: "PASCAL P Compiler
Implementation Notes"; ETH Zurich, 1975.
[RTh76] D. M. Ritchie and K. Thompson: "The UNIX Time-sharing System";
Comm. of the ACM, vol.17, no.7, Feb. 1976, pages 365-375.
[Rus78] Richard M. Russell: "The Cray-1 Computer System"; Comm. of the
ACM, vol. 21, no. 1, Jan. 1978, pages 63-72.
[Per78] Daniel R. Perkins: "Standard Universal P-code Document"; UCSD,
August 1978.
[WiB70] Gio Wiederhold and Gary Breitbard: "A Method for Increasing The
Modularity of Large Systems"; IEEE Computer, Vol. 3, no. 2,
March-April 1970, page 30.
[Wir75] N. Wirth: "An Assessment of the Programming Language PASCAL"; IEEE
Transactions on Software Engineering, vol SE-1, no. 2, pages
192-198, 1975.
Page 17
The following documents have been produced as part of the S-1 work and
have been included in the final or intermediate reports.
[ccn78] Fernando Castaneda, Frederick Chow, Peter Nye, Dan Sleator, and
Gio Wiederhold: "PCFORT, A Fortran to P-code Translator"; S-1
project document FORFIX-1, Octoober 20, 1978.
[giw77] Erik J. Gilbert and David W. Wall: "P-code Intermediate Assembly
Language"; S-1 project document PAIL-3, July 18, 1977.
[gwa78] Erik J. Gilbert and David W. Wall: "Specification for Run-time
support for PASCAL"; S-1 project document PRUN-0, March 23, 1978.
[han77] Hon Wah Chin: "Considerations for Operating System Design"; S-1
working document, Sept. 77.
[hen78] John Hennessy and Forest Baskett: "Proposal for Extensions to
Pascal"; S-1 working document, Nov. 78.
[hhw78] Brent Hailpern, Bruce Hitson, Curt Widdoes, et al.: "S-1
Programmers Manual"; S-1 project document SMA-3, November 29,
1978.
[haw78] Brian Harvey and Gio Wiederhold: "Level-0 Operating System
Specification"; S-1 project document OS0-4, January 30, 1978.
[kew78] Arthur Keller and Gio Wiederhold: "S-1 Intermediate Loader
Format"; S-1 project document LDI-8, November 27, 1978.
[kwz78] Peter B. Kessler, L. Curtis Widdoes, jr., and Polle T. Zellweger:
"S1 Linkage Protocol"; S-1 project document LP-1, August 31, 1978.
[mww77] Thomas M. McWilliams, Lawrence C. Widdoes and Lowell L. Wood:
"The S-1 Multiprocessor: Architecture"; S-1 project Document
SMA-2, November 9, 1978.
[nem77] Peter Nye and Ramez ElMasri: "S-1 Instruction Set Code Assignment
Table"; S-1 project document CAT-1, August 15, 1977.
Page 18
[okk78] Mohammad Olumi and Javad Khakbaz, modified by Arthur Keller: "S-1
Loader Format"; S-1 project document LDF-5, January 13, 1978.
[psw77] Larry Paulson, Dan Sleator, and Gio Wiederhold: "Specification for
an S1 FORTRAN compiler"; S-1 project document FOR-2, December 15,
1977.
[s1s78] S-1 software group: "S-1 Software"; Compendium vols 1 & 2, July
27, 1978.
[wag78] David W. Wall and Erik J. Gilbert: "SOPAIPILLA Maintenance
Manual"; S-1 project document SOPADOPE-1, March 23, 1978.
[wie77] Gio Wiederhold: "S-1 Characterset Definition"; S-1 project
document CHS-1, September 6, 1977.
[wie78M] Gio Wiederhold: "Programming Multiprocessors, an assessment"; S-1
working document, Jan. 78.
[wie78] Gio Wiederhold: "Multi-mode approach to operating system
development"; S-1 working document, Nov. 78.
Page 19
LIST OF ATTACHMENTS
1) LDI-8 S-1 Intermediate Loader Format
Arthur Keller and Gio Wiederhold
November 27, 1978
2) LDF-5 S-1 Loader Format
Mohammad Olumi and Javad Khakbaz
Modified by Arthur Keller
January 13, 1978
3) SOPADOPE-1 SOPAIPILLA Maintenance Manual
David W. Wall and Erik J. Gilbert
March 23, 1978
4) CHS-1 S-1 Characterset Definition
Gio Wiederhold
September 6, 1977
5) OS0-4 Level-0 Operating System Specification
Brian Harvey and Gio Wiederhold
January 30, 1978
6) FIXFOR-1 PCFORT: A Fortran-to-Pcode Translator
User and Maintenance Manual
Fernando Castaneda, Frederick Chow, Peter Nye, Dan Sleator, and
Gio Wiederhold
October 3, 1978
notes from ARK
**** File 1) FINAL.78[1,GIO], Page 4 line 22
compatibility [right]
**** File 1) FINAL.78[1,GIO], Page 6 line 4
eprocedures. [I was wrong, but this doesnt look ok either ]
**** File 1) FINAL.78[1,GIO], Page 9 line 29
behavior [down with the british?]
**** File 1) FINAL.78[1,GIO], Page 15 line 37
necessary [right]
**** File 1) FINAL.78[1,GIO], Page 17 line 4
1) [ANS64] American Standard Association, X3.4.3: "FORTRAN vs. BASIC
[huh cant see difference ]
**** File 2) FINAL.ARK[1,GIO], Page 17 line 4
ANSII: [right]
1-Dec-78 01:20:50-PST,1173;000000000000
Mail from SU-AI rcvd at 1-Dec-78 0120-PST
Date: 1 Dec 1978 0117-PST
From: Lowell Wood <LLW at SU-AI>
Subject: Contract Extension
To: wiederhold at SUMEX-AIM
CC: LCW at SU-AI, BS at SU-AI, LLW at SU-AI, JRS at SU-AI,
CAR at SU-AI
In case there is any concern regarding the contact between SU-CS and LLL
of which you are the PI, and of which the 2 month extension expired this
past day, I have authorized/directed the cognizant LLL people (in Milt
Eaton's area) to extend the 2 month extension until Dec. 31, 1978 (i.e.,
by 1 more month). This re-extension serves the purposes of using up most
of the roughly 27 K$ left in the contract kitty as of 30 November (which
figure I know accurately, as I received an invoice for expenses thru 30
Nov. quite early this month!), and of giving the LLL-DoE machinery
another few weeks to complete the processing of my pending request to fund
the follow-on contract corresponding to your proposal. Seemingly the only
action you need to take in this connection is to hold onto your Final
Report for another month, and update it accordingly at end-December.
Lowell
1-Dec-78 02:04:35-PST,825;000000000000
Mail from SU-AI rcvd at 1-Dec-78 0204-PST
Date: 1 Dec 1978 0203-PST
From: Lowell Wood <LLW at SU-AI>
Subject: Contract Re-Extension Addendum
To: wiederhold at SUMEX-AIM
CC: LLW at SU-AI, LCW at SU-AI, BS at SU-AI, JRS at SU-AI,
CAR at SU-AI
Correcting/extending my earlier note concerning a one-month extension of
the instantly expired two-month extension of your present contract: the
SU Accounting Office reported that your November costs were 25.3 K$, that
aggregate costs against the contract-allocated total of 157.4 K$ thru Nov.
30th were 124.3 K$, and that 33.1 K$ of contract-allocated funds are thus
uncommitted as of the nominal Nov 30 contract expiration date. This seems
an adequate pad thru Dec 31, as noted earlier, being 30+% above your Nov.
cost rate.
Lowell
1-Dec-78 02:50:20-PST,1403;000000000000
Mail from SU-AI rcvd at 1-Dec-78 0250-PST
Date: 1 Dec 1978 0249-PST
From: Lowell Wood <LLW at SU-AI>
Subject: Last Contract Extension Afterthought
To: wiederhold at SUMEX-AIM
CC: LLW at SU-AI, LCW at SU-AI, BS at SU-AI, JRS at SU-AI,
CAR at SU-AI
I will be modifying my guidance to the LLL Procurement people later today
with respect to the end of the re-extension period. Since both the LLL
and DoE bureaucracies are even more torpid than usual between
pre-Christmas Eve and post-New Year's Day, I will be asking for an
extension through 15 Jan. 79, rather than 31 Dec 78, so that the 8 K$ of
pad, relative to projected December expenses, will be available to meet
early January costs, just in case the paper-shufflers don't complete their
rituals before the Christmas holidays. I will of course be working to see
that this is an unnecessary precaution.
Also, if you should be contacted by anyone from this side of the Bay, you
will recall that you and I negotiated this no-cost extension 'for
completion of documentation, transfer to LLL and support of evaluation at
LLL of S-1 software developed by Professor Wiederhold's group under the
contract.' However, I anticipate no problems with respect to what the
Procurement people presently view as a very routine no-cost extension
matter.
Lowell
2-Dec-78 19:35:40-PST,3408;000000000001
Mail from SU-AI rcvd at 2-Dec-78 1935-PST
Date: 2 Dec 1978 1932-PST
From: Brent Hailpern <BTH at SU-AI>
To: s1arch at SU-AI
∂02-Dec-78 1803 LLW
To: BTH
CC: LLW
∂02-Dec-78 1520 BTH arbitrary changing of sma3
To: s1arch at SU-AI
Who was the idiot that did a global change of S1 to S-1 in the new
architecture manual? You manage to garbage any formula using the S1
operand and references to files on [SMA,S1]. It had been decided long ago
to use S1 instead of S-1 and you should have consulted one of the authors
(BTH or BLH) before doing such a massive change. A warning to people:
keep your mits off SMA3! If you have a change you would like done contact
BTH or BLH (or LCW or JBR or MLB).
[I made the change of S1 to S-1 in SMA-3, which I edited (superficially)
at LCW's invitation. I wish to make it utterly clear that 'S-1' will
ALWAYS be used in place of 'S1' (or any other substitutes) in ALL Project
documents which may be distributed outside the Project, until further
notice from me. Any alternate designation which strikes anyone's fancy
may be used internally, but 'S-1' will continue to be the external
designation. The 'we' who agreed to change from 'S-1' to 'S1' definitely
did not include me, and I'm the one to whom the time-invariance of the
Project name is most important. Cosmetic changes perceived as
improvements will not be allowed to clutter up the perceptions of the
Project on the part of the people with whom I deal for Project support and
appreciation, who don't have the time to follow all our cute little name
changes and aliases. I regret any formula garbaging--I specifically
changed back all ',S-1]' changes to ',S1]', after the Project name
reference CORRECTION, and verified that this change-back was correctly
made on two different pages; I therefore don't know what the problem is to
which you referred. Lowell]
[As to your final comment, I dont know what happened about ",S1]" but when
I fixed the alterations E made the change back to "S1]", so .... As to
the S-1, S1 controversy, I suggest Lowell and Curt get their act together.
Curt gave Bruce and I the directive that the name was to change to S1 at
the beginning of summer quarter. Personally, arguing over a hyphen seems
very foolish, but Im willing to make the change or leave it be as you on
high desire ... BUT MAKE UP YOUR MINDS! Bruce and I have busted or
collective butts over this project and everytime it nears completion
someone above us decides "no, here are another N changes...". I perfectly
willing to keep making patches on the manual until the end of this
quarter, but if you people dont decide to stop changing your minds soon,
you will never get a fiscal year report out.
I would like to reiterate to all of you, no matter how important, that are
not directly connected with writing the manual. DONT MAKE ANY MAJOR OR
GLOBAL CHANGES TO THE MANUAL! You dont realize how we have hard we have
attempted to be consistent and clear, and many of you are not familiar
with POX. Any casual change will very likely destroy that consistency or
cause a POX error. As far as I am concerned, only Bruce, Curt, Jeff,
Marc, and myself are qualified to make such changes.
I patiently await the ex cathedra decision on S-1 vs. S1. Brent]
2-Dec-78 01:23:58-PST,2232;000000000001
Mail from SU-AI rcvd at 2-Dec-78 0123-PST
Date: 2 Dec 1978 0122-PST
From: Lowell Wood <LLW at SU-AI>
Subject: The Virtues of Collective Bargaining
To: LCW at SU-AI, wiederhold at SUMEX-AIM, TM at SU-AI, PMF at SU-AI,
JBR at SU-AI, EJG at SU-AI, GDG at SU-AI, HWC at SU-AI,
CAR at SU-AI, JRS at SU-AI, WRB at SU-AI, LRM at SU-AI
CC: LLW at SU-AI
Collective bargaining is rearing its nominally ugly head in the hitherto
hallowed precincts of the University of California, moreover at an
unexpectedly rapid pace (given the leisurely time constants of the
perceptions of some of the more senior of us). Therefore, the top
management of our beloved Laboratory will not be able to devote itself to
reviewing the programs of its various satrapies (such as the Physics
Department) until sometime next year, it was announced this past PM, due
to the now-urgent necessity of coping with this Dire Threat. In
particular, the Physics Program Review date has been slipped from 13
December until sometime in the second half of January. While Curt's
excellent, comprehensive presentation of the Project at today's first
rehearsal of the Program Review will therefore have to be updated to
include another whole month's technical progress and
escalation-of-promises, I'm sure he will endure it gladly in order that we
can develop an even more stunning dog-and-pony show for the occasion.
The implications of this schedule shift for near-term endeavor are that we
should focus exclusively on Open House-related demonstrations of
capability, particularly those concerning SCALD (which is what most of our
guests will be most keenly interested in, I am advised). Right after
getting SCALD or at least SUDS running for demos comes FORTRAN and Pascal
capability, including simple graphics. Effort on these fronts is to be
enhanced by cutting into Lab-oriented capability demos, specifically
including ZUBEN, SIMPLE, ADI, HYDRO, and MC (which, however, continue to
be of great interest for the Physics Program Review).
Questions or comments to Curt or me.
Lowell
-------